Power Programmierung 2

home *** CD-ROM | disk | FTP | other *** search

/ Power Programmierung 2 / Power-Programmierung CD 2 (Tewi)(1994).iso / c / library / dos / netz / killco / killconn.doc < prev next >

Wrap

Text File | 1991-04-20 | 12.1 KB | 313 lines

DOCUMENTATION FOR KILLCONN.EXE (Copyright 1991 Thomas R. Bruce) In general: KillConn is a utility which permits authorized users to clear workstation connections on a Novell network via the command line or from a batch file. It is useful for clearing stations prior to running system backup and maintenance procedures, particularly if these are being run unattended. The user should keep in mind that however useful it may be it is also somewhat dangerous, particularly if it is being used in the unattended mode. KillConn has been tested under Netware 2.15 and 3.10 and it is therefore probably safe enough to assume that it will work well with any version of Netware above 2.10. (I'd love to hear about any exceptions to this naive generalization). ////////////////////////////////////////////////////////////////////// Additional notes for version 1.1: Version 1.1 is appearing only a few days after version 1. This is owed not (thank heavens) to any major flaws in the original software, but instead to the astute comments and observations of Gary Banks at the University of Virginia Law School; 1.1 adds a couple of features and solves some problems Gary was having with it. (Report bugs and I'll mention your name too....) First, KILLCONN now attempts to disconnect the victim five times before failing with an appropriate error message to the log file; Novell versions prior to 2.15 seem to have some problems with a single pass. Previously KILLCONN's failures went unnoticed in the log. You can change the retry count with the RETRIES=nn command line parameter (see below). Second, I thought that some of the more merciful among you-- those who are not running this program late at night-- might appreciate the ability to warn users prior to dropping their connections. See the WARNING=nn parameter below. ////////////////////////////////////////////////////////////////////// Safety nets: KillConn cannot be run by anyone who does not have console operator rights on a target file server. It can also be configured (via the confirm=YES option -- see below) to require a keyboard response before it clears anyone, if you are not running it unattended. You can also set up a Netware group called IMMORTAL; KillConn will skip any of its members no matter what. This is handled on a per-file-server basis, so if you're running KillConn on an internetwork, you'll have to set up the group on each server; whether you do this with the same members on all servers or not is up to you. KillConn will not clear ANY connection belonging to a user with the same login_name as the workstation from which it is being run. This can be a problem if the user running KillConn is logged in from multiple locations, and you wish to retain only one, but I had to draw the line somewhere. Using the WARNING=nn parameter permits you to give the user an appropriate amount of warning before disconnecting her. Of course, too short a length of time is open to interpretation as a subtle psychological torture.... ////////////////////////////////////////////////////////////////////// Power tools: KillConn can be configured to clear groups of users in two ways- either by using the group=SOMEGROUP parameter on the command line, which will cause all members of a Netware group to be cleared, or by using wildcard characters (* and ?, just as with DOS) in the user= command line parameter (for example user=LABMACHINE*). Of the two methods, I prefer using the 'group =' parameter. It involves a little more administration, but it's also a great deal more obvious what's going on and more difficult to make unintentional errors. KillConn is set up to work automatically on all servers on an internetwork; you can restrict its scope with the 'server=' command-line parameter if you only want to clear connections from one. The 'user=' and 'group= ' parameters are still in effect (indeed, one or the other is required). Of course, the workstation from which KillConn is run must be attached to any server you wish to clear, regardless of how you set the scope. If you experience trouble with certain stations not clearing when you know KILLCONN has found them, you may set KILLCONN to retry each station a number of times before moving on. See RETRIES=nn below. ////////////////////////////////////////////////////////////////////// Notification: KillConn sends a regular Novell-type broadcast message to all stations which it clears. The message give the date and time at which the station was cleared, presumably for the victim to find the next morning. Note that the date and time are taken from each server individually, so that occasional discrepancies will result if your servers do not have their system times synchronized. You may also, via the 'log= logfilename' and 'logadd= logfilename' parameters, configure KillConn to keep a log of its nefarious activities. Using 'log=' causes an existing logfile with the same name to be overwritten; 'logadd=' appends new information to an existing logfile. ////////////////////////////////////////////////////////////////////// Imaginative uses: Primarily, KillConn is intended to clear stations out of the way so that you can grab the system away from the end-users and get on with whatever it was you wanted to do. I can also see it being used as a way of plugging security holes created by users who leave workstations running at all hours. ////////////////////////////////////////////////////////////////////// ENOUGH, ALREADY! How do I use it?: Command-line parameters: USER=SOMEBODY USER=WILD*CARD or WILD???? GROUP=NOVELL_GROUP (one and only one required) USER=SOMEBODY will disconnect user SOMEBODY anywhere they are logged in, no matter how many times they are logged in, unless SOMEBODY is a member of IMMORTAL or the scope is restricted via the SERVER= option. USER=WILD*CARD will similarly disconnect all users with names that match the wildcard pattern (which follows DOS rules- * represents any number of characters, ? only one). GROUP=NOVELL_GROUP will disconnect all members of a group. Note that if the group membership varies from server to server so will the people disconnected; KillConn looks at only one bindery at a time. You must use one of these and you may use only one. Anything else you want to do can probably be handled either by setting up an appropriate group with SYSCON or by running KillConn repeatedly from a batch file. //////////////////////////////////////////////////////////////////////// SERVER=SERVERNAME KillCon ordinarily works across all file servers to which the workstation running it is attached (internetwork scope). If you want to restrict this, you can limit it to server SERVERNAME by setting this parameter. //////////////////////////////////////////////////////////////////////// CONFIRM= YES or CONFIRM = NO The default is CONFIRM= NO, so be careful. Normally, KillConn doesn't ask anyone's permission before it blasts some heathen off the network. If you set CONFIRM=YES at the command line, an operator at the workstation running KillConn will be able to abort it on a case-by-case basis. I recommend using this the first time you try a wildcarding scheme, just to make sure nothing untoward shows up. //////////////////////////////////////////////////////////////////////// LOG=filename or LOGADD=filename If either one of these appears on the command line, KillConn will write a log to file 'filename'. Of course, 'filename' may be a full DOS path up to 255 characters in length. Using LOG= causes an existing file of the same name to be overwritten; LOGADD= will create the file if it doesn't exist, and append to it thereafter. //////////////////////////////////////////////////////////////////////// HELP -H /H Any one of these three produces a cryptic and potentially frustrating help screen, as is traditional in the industry. ////////////////////////////////////////////////////////////////////// WARNING=nn Sends the user a broadcast message a minimum of nn seconds before disconnecting them; you can set this as high as is necessary to allow people to log out. ////////////////////////////////////////////////////////////////////// RETRIES=nn By default, KILLCONN will attempt a disconnection five times before giving up; it seems that on certain networks stations do not respond quickly enough. You can set the retry count higher or lower with this parameter. There's probably no advantage to setting it lower unless you're in one heck of a hurry. ////////////////////////////////////////////////////////////////////// EXAMPLES: Let's suppose we have a three-server internetwork with servers named BOZO, CARDOZO, and SHLOMO-- I'm running KillConn as user BIGDEAL, who has console privileges on all three servers. KILLCONN USER=TOM would clear TOM off of all three, provided that the workstation is logged into all three. KILLCONN USER=TOM SERVER=SHLOMO LOG=K:\HOME\BIGDEAL\KILLED.LOG would kick TOM off SHLOMO only, and record this fact in the file KILLED.LOG in the specified directory. If we then ran KILLCONN USER=TO* LOG=K:\HOME\BIGDEAL\KILLED.LOG users TOM, TORRID, TORRENTIAL, and TORTOISE would be cleared from all servers. The log file would be overwritten with this information. To retain the information from our previous session, we would use KILLCONN USER=TO* LOGADD=K:\HOME\BIGDEAL\KILLED.LOG If we wanted to skip the log, but have individual control over each of the four users, we could use: KILLCONN USER=TO* CONFIRM=YES and manually confirm each clear from the workstation running KillConn. Finally KILLCONN GROUP=DINGBATS SERVER=BOZO would zap all users in the group DINGBATS from server BOZO. Of course, this assumes that none of the people mentioned above are members of the IMMORTAL group. Got it? ////////////////////////////////////////////////////////////////////// YOUR RIGHT TO USE THIS PRODUCT: KillConn is being marketed under a 'conscience-ware' scheme, whereby I as author am not really seeking any compensation, but am also very open to the possiblity that people might send me $10 or so if they find it useful. More to the point, I really enjoy hearing from people who are using the silly thing; it's nice to know someone's using something you built. So, regardless of whether you send cash or not, drop me a line or give me a call. As I say, it's nice to feel that this stuff isn't getting pitched into a void. Naturally, though I won't strain your credulity by claiming that I like to get bug reports, I _do_ want to hear about them, and I will continue to maintain this code (on an admittedly as-time-permits basis) for as long as people report problems. Believe it or not I get a charge out of writing little utilities and would therefore love to hear about any ideas anyone may have for other small tools, new features, and so on. KillConn _is_ copyrighted, and may not be distributed commercially or in conjunction with any commercial product without the author's permission; I also expect that should you post it to a bulletin board or other public forum you will include this documentation, copyright notice, and disclaimer. The author, Thomas R. Bruce, may not be held liable for any damages, loss of business, or other direct or indirect consequences of your use of this product. Put another way: DISCLAIMER - AGREEMENT Users of KillConn must accept this disclaimer of warranty: "KillConn is supplied as is. The author disclaims all warranties, expressed or implied, including, without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of KillConn." That said, enjoy using KillConn. And don't forget to write: Thomas R. Bruce 147 Chestnut St. E-22 Ithaca, NY 14850 (607)-273-2661 In cyberspace: lemuel!tom@cs.cornell.edu 75360,542 (Compuserve), which I don't check real often.